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ABSTRACT 



A public key escrow system is adapted to have a proof of 
knowledge protocol for a certificate. The certificate is signed 
with RSA and is proved using a protocol based on the 
Guillou-Quisquater proof of knowledge scheme, or other 
proof of knowledge protocol. Interactive and non-interactive 
protocols are disclosed. 
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CRYPTOGRAPHIC KEY ESCROW SYSTEM 
HAVING REDUCED VULNERABILITY TO 
HARVESTING ATTACKS 

FIELD OF THE INVENTION 

The invention relates to a public-key Cryptography sys- 
tem with key escrow encryption. More particularly, the 
invention relates to a method for preventing harvesting of 
information, especially a certificate, for an escrow key, 
exchanged in the key escrow protocol Preventing harvest- 
ing of information is achieved by using proof of knowledge 
techniques in the escrow verification protocol. 

BACKGROUND OF THE INVENTION 

Key escrow cryptography systems allow authorized par- 
tics to retrieve escrowed keys for encrypted communications 
from escrow and use them to obtain the authorized system 
user's current session key. An authorized party in possession 
of the session key can decrypt the user's intercepted com- 
munications. Authorized parties are considered to be law 
enforcement agencies, national security agencies, corporate 
managers or supervisors and others who at times need access 
to cryptography communications. 

In a public key escrow cryptography system, each user 
member of the system has a public escrow key/private 
escrow key pair. The private escrow key member of the pair 
is divided into parts and the respective parts are deposited 
with two ox more key escrow agents. A user member sends 
in each communication a law enforcement access field 
(LEAF) containing the current session key encrypted by the 
public escrow key corresponding to the combined private 
escrow key parts deposited with the escrow agents. In a law 
enforcement environment a court order (for wiretapping or 
eavesdropping) is obtained by the law enforcement agency 
authorizing the key escrow agents to release the private 
escrow key parts. The law enforcement decryptor combines 
the key pads to produce the private escrow key and uses it 
to decrypt the law enforcement access field containing the 
session key being used in the current communication. With 
the session key thus obtained, the law enforcement agency 
can decipher the intercepted communication. 

In the public key escrow cryptography system, the 
receiver (by convention called Bob) of the communication 
reconstructs the law enforcement access field to verify that 
the received law enforcement access field in the communi- 
cation is valid and correct for the current encrypted message. 
This procedure counters single rogue attacks (an attack on 
the system by a rogue user), by indicating to the receiver that 
the communication is from a sender (by convention called 
Alice) who has included a law enforcement access field in 
the communication and is properly using the escrow proto- 
col. In order for Bob to reconstruct the law enforcement 
access field. Alice includes in the communication an escrow 
verification string (EVS) encrypted wife the current session 
key (the current session key is known to both Alice and 
Bob). The escrow string incudes Alice's public escrow key 
and a certificate for Alice's public escrow key in Alice's 
program. Only an authorized public escrow key should have 
a certificate, so if the signature verifies. Bob knows that the 
escrow agents have the corresponding private escrow key. 
Bob re-encrypts the session key with Alice's public escrow 
key and compares the result to the received law enforcement 
access field to see that they are the same. 

Bob. or any other member with which Alice rammuni- 
cates can copy. i.e.. harvest Alice's public escrow key and 
the certificate. With the certificate copy. Bob can imperson- 
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ate Alice, by communicating with others using a LEAF 
formed with Alice's public escrow key which makes it 
appear to the law enforcement decryptor mat Alice is 
involved in the communication. The law enforcement 

5 decryptor then monitors all of Alice's communications, a 
situation which causes Alice's communication to be sub- 
jected to unwarranted and unauthorized exposure. Bob can 
also harvest the certificates for may users and variably use 
certificates among the collection during subsequent commu- 

io ni cations to confuse law enforcement 

Encrypting the certificate with the session key protects it 
from eavesdroppers. However, Bob knows the session key 
and must see the certificate to verify that Alice's purported 
public escrow key is valid, so Bob automatically has the 

15 capability to harvest Alice's and other users' certificates, 
public escrow key and other information. 

The public key escrow cryptography system and the 
harvesting attack is further described in an article entitled "A 
New Approach to Software Key Escrow Encryption'' by 

20 Balenson et al (1994). This article also suggests a solution to 
the harvesting problem that involves splitting fee session 
key and encrypting each part with one of fee respective 
public keys of the two escrow agents. This procedure still 
uses a LEAF and an escrow verification string, but does not 

25 contain information that can be used by the receiver to 
impersonate the sender. However, the escrow agents are 
required to be on-line and involved with every decryption of 
a new session key. 

30 SUMMARY OF THE INVENTION 

The reason that harvesting is possible in the first instance 
is because Alice gives away too much information. Not only 
does Alice convince Bob mat she has a valid escrow public 
35 key by showing Bob her certificate, Alice also enables Bob 
to transfer that knowledge to someone else. All Alice really 
needs to do is to convince Bob that she has a certificate for 
her public escrow key. Alice does not need to show Bob the 
certificate. By the application of interactive or non- 
40 interactive proof of knowledge techniques, Alice can prove 
to Bob feat she knows the signature on fee certificate, 
without revealing fee signature or anything about fee 
signature. As a result, no information is made available that 
can be harvested, whereby a user could be impersonated. 

45 BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 illustrates a known public key escrow cryptogra- 
phy system; 

FIG. 2 is a flow chart illustrating a first proof of knowl- 
50 edge protocol; 

FIG. 3a is a flow chart illustrating a non-interactive proof 
of knowledge protocol; and 

FIG. 3b is a flow chart illustrating a further non- 
52 interactive proof of knowledge protocol 

DETAILED DESCRIPTION OF THE 
INVENTION 

FIG. 1 illustrates fee protocol of the prior art public key 
60 escrow system. Unit 10 represents the sending software 
program. Alice, unit 20 fee receiving software program. 
Bob, unit 30 fee law enforcement decryptor, unit 40 a first 
key escrow agent and unit 50 a second key escrow agent. 
In sending software program unit 10, M is the message to 
65 be encrypted wife fee session key KS being used by Alice 
the sender and Bob the receiver. Encrypting message M with 
the session key KS produces fee encrypted message C, 
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designated as C={M}KS. The sending software program 
Includes a family public key KFJmb, a program unique 
identifier UIP. a program unique public key KUpub and a 
UIRKUpub parameter signed by KEPFpriv the key escrow 
programming facility private key 

{UIP, KU pub}KEFFpriv. 

The signed parameter is the certificate for Alice's public key. 
Alice generates and sends a law enforcement access field 
LEAF by encrypting the session key KS under the program 
unique public key KUpub. concatenating the result with the 
program unique identifier UIP and encrypting the concat- 
enated value with the family key KFpub, The LEAF is 
symbolized by 

LEAF={{KS}KUpubfUlP}KFpub. 

Alice also sends an escrow verification string EVS. This 
string includes Alice's program unique identifier UIP, pro- 
gram unique public key KUpub, and the signature applied to 
these two parameters by the key escrow prograrnrning 
facility KEPFpriv. This string is encrypted with the session 
key KS. Thus 

EVS={UIP, KUpub 7 fUIP r KUpub}KEPFpriv}KS 

The receiving software program unit unit 20, receives the 
encrypted message C={M}KS and decrypts it using the 
session key KS that it shares with the receiver. However, first 
the LEAF must be authenticated. This is done by decrypting 
the escrow verification string EVS and using parameters 
therein to reconstruct the LEAF. The receiving software 
includes the key escrow programming facility public key 
KEPFpub and the public family key KFpub. The receiving 
unit Bob uses the session key KS to decrypt EVS recovering 
Alice's UIP. KUpub and the signature. Using KEPFpub to 
verify the signature, Alice's UIP and KUpub are verified. 
Bob's program then recalculates the LEAF using KS. 
KFpub and Alice's UIP and KUpub and compares it with the 
received LEAF. 

Law enforcement decryptor LED, unit 30, wanting to 
intercept and decrypt the encrypted message C has to 
recover the session key KS used to encrypt the message M. 
The session key KS is contained in the LEAF. With the 
family private key KFpriv provided to the LED, LED can 
decrypt the LEAF to retrieve {KS}KUpublUIR With UIP 
and a proper court order, LED can obtain from the respective 
escrow agents of units 40 and 50 the escrowed components 
KUprivl and KUpriv2 of Alice's program unique private 
key. combine them to form KUpriv and decrypt the session 
key KS. With the session key KS the law enforcement 
decryptor can decrypt encrypted message C to obtain mes- 
sage M. 

The problem of harvesting as described above arises when 
the receiver Bob, a participating member in the key escrow 
system or network, records the information exchanged in the 
key escrow protocol and impersonates Alice using the 
recorded information. Specifically. Bob copies Alice's cer- 
tificate for Alice's escrow public key {UIP, 
KUpub}KEPFpriv which Bob must see to verify that Alice's 
purported escrow public key KUpub is valid. With this 
information Bob can modify a copy of the product using a 
LEAF constructed with Alice's UIP and KUpub. By imper- 
sonating Alice in a future communication. Bob causes the 
LED to believe that Alice is involved in the communication. 

The reason that harvesting is possible is that AHce gives 
away too much information. Not only does Alice convince 
Bob that Alice has a valid escrow public key; AHce also 
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enables Bob to transfer this knowledge to someone else, But, 
all Alice really needs to do is convince Bob that Alice has a 
certificate for her escrow public key KUpub. Alice does not 
need to show Bob the certificate. 

5 Turning to the invention, consider the procedure where 
the certificate is signed with RSA. The body of the certificate 
contains the escrow public key KUpub. The body is first 
hashed and the resulting hash is encrypted with the certifi- 
er's RSA private key. This provides a signature which is 

10 appended to the body of the certificate. 

The certifier's RSA public key is known to Bob. Bob can 
then decrypt the signature to recover the hash, If the recov- 
ered hash matches the hash of the certificate's body, he 
accepts the certificate. In this procedure, the signature is sent 

15 to the receiver. 

A way to do this, without sending the signature, is to use 
proof of knowledge techniques. All Alice needs to prove to 
Bob is that Alice knows the signature on the certificate, i.e.. 
the RSA encryption of the hash of the certificate body. Using 

20 proof of knowledge techniques Alice can prove this without 
revealing anything about the signature itself. 

Proof of knowledge techniques are known in verification 
schemes. See the article "A Practical Zero-knowledge Pro- 
tocol Fitted to Security Microprocessor Minimizing Both 

25 Transmission and Memory" by Guillou and Quisquater, 
herein incorporated by reference into the disclosure. 

The following protocol, based on the Guillou-Quisquater 
scheme, is an efficient way to achieve the proof of knowl- 
edge property. The parameters are as follows: 

30 n - the certifier's RSA modulus 
e - the RSA public exponent 
h - the hash of the certificate body 
S - the signature on the certificate. 
Thus, the hash h=S*mod n. 

35 Alice proves that she knows S in the following steps, and 
as illustrated in the flow chart of FIG. 2. 

1. Alice generates a random number r between 1 and n-1. 

2. Alice computes x=r* mod n 
2a. Alice sends x to Bob 

40 3. Bob generates a random number c between 0 and e-1 
3a. Bob sends c to Alice 

4. Alice computes y==rS c mod n 
4a. Alice sends y to Bob 

5. Bob checks the y tf =xh c mod n 
45 6. If so. Bob accepts proof. 

Bob, having accepted proof of the signature, uses the 
session key KS to decrypt the escrow verification string 
EVS={UIP.KUpub}KS to obtain the parameters UIP. 
KUpub, uses these parameters to reconstruct the LEAF, and 
50 compares the reconstructed LEAF with the LEAF sent by 
Alice. 

As Guillou and Quisquater show. If Alice does not know 
the signature S. Alice will be caught with probability 1-1/e 
(here e being the certifier's RSA public exponent). To 

55 increase the probability further, one can repeat the protocol 
as indicated in step 7. Replay is prevented, since Bob's 
challenge c is random. Furthermore, no matter what Bob 
sends to AHce. Bob cannot learn anything more about 
signature S than he could have learned by himself, with a 

60 similar amount of work (just a factor of e more). In 
particular, Bob cannot learn enough to impersonate Alice to 
someone else. 

Non-interactive embodiments of the proof of knowledge 
protocol are illustrated in FIGS. 3a and 3b. The parameters 
65 for n, e. h and S are the same as above far the use with RSA 
signatures. In these non-interactive embodiments. Alice, 
without Bob's participation generates and computes the 
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values x. y, c and sends x and y or c and y to Bob. Bob 
generates the value c in the same manner as Alice. In these 
embodiments. Bob is checking to see that Alice has correctly 
generated c. The non-interactive embodiments are advanta- 
geous in that they can be used in a store and forward 
environment such as electronic mail. 

In the non-interactive embodiment of FIG. 3a, Alice and 
Bob both generate c in the same manner. The value of c is 
made dependent upon some non-repeating function such as 
a timestamp or the session key. Alice computes x and y and 
sends these values to Bob. Bob solves the equation of y*=xh c 
mod n using his generated value for c and the received 
values of x and y. If the equality holds, then Bob accepts the 
proof. Hie procedure for Alice proving that she knows S, the 
signature on her certificate is illustrated in the flow chart of 
FIG. 3a. 

U. Alice generates a random number r between 1 and n-1. 

12. Alice computes x=r* mod n. 

13. Alice generates a number c between 0 and e-1. 

14. Alice computes y^rS c mod n. 

15. Alice sends x and y to Bob. 

16. Bob generates c in the same manner as Alice. 

17. Bob checks that y <r =xh c mod n, 

18. IF so. Bob accepts the proof. 

To keep Alice from cheating and choosing the value of c 
before x. which would enable Alice to provide a solution 
easily, the value of c is made dependent upon x, as for 
example through a hash function. In addition, to prevent 
replay, the value of c is made dependent upon some non- 
repeating function, such as a timestamp or the session key. 
Bob is required to generate c in the same manner that Alice 
generated c. Bob then checks that Alice has computed the 
value of c appropriately. 

In the non-interactive embodiment of FIG. 3b, Alice 
generates and computes the values x. y and c and sends y and 
c to Bob. Bob then checks to see that Alice has properly 
generated c by comparing the received value c with the value 
of c resulting from his solving the equation of ^^xif mod 
n for x and computing c in the same manner as Alice. FIG. 
3b illustrates the protocol as follows: 

21. Alice generates a number r between 1 and n-1. 

22. Alice computes x==r* mod n, 

23. Alice generates a number c between 0 and e-1, 

24. Alice computes y=rS c mod n. 

25. Alice sends y and c to Bob. 

26. Bob solves y*=*xh c mod n for x, 

27. Bob generates c in the same manner as Alice. 

28. Bob checks that his value for c equals the value of c 
received from Alice, 

29. If so. Bob accepts the proof. 

Again, the value of c generated by Alice is made dependent 
upon x. e.g., through a hash function, and some non- 
repeating function, such as a timestamp or the session key. 

Encryption programs are used for the protection of infor- 
mation transmitted over private and public networks such as 
Internet and electronic banking systems. The programs are 
for installation in telephones, encryption cards, data bases 
and files. 

The invention has been described using RSA signatures, 
but any certificate signature scheme can be used, as for 
example, DSAand HgamaL Similarly, other techniques may 
be adapted, e.g., that of Fiat-Shamir which provide a proof 
of knowledge without transferring useful information (See 
Feige et aL, "Zero-Knowledge Proofs of Identity", Journal 
of Cryptohgy, 1 (2): 77-94 (1988)) herein incorporated by 
reference. 

While the invention has been described in connection 
with what is presently considered to be the most practical 
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and preferred embodiment, it is to be understood that the 
invention is not to be limited to the disclosed embodiment, 
but on the contrary, is intended to cover various modifica- 
tions and equivalent arrangements included within the spirit 
and scope of the appended claims. 
What is claimed: 

1. A method of preventing certificate harvesting in a 
public key escrow system with verification of escrow pro- 
tocol between communicating members comprising: 

sending by a sending member an escrow verification 
string containing the sending member's public escrow 
key but not containing a certificate; and 

engaging in a proof of knowledge protocol with a receiv- 
ing member to prove to the receiving member that said 
sending member has a valid certificate.. 

2. A method as in claim 1 wherein said proof of knowl- 
edge protocol is a zero-knowledge protocol 

3. A method as in claim 1 wherein said proof of knowl- 
edge protocol includes the steps: 

a) generating, by the sending member, a random number 
r between 1 and n-1; 

b) computing, by the sending member, a value x, where 

X=t" XDOd K 

c) sending x to the receiving member, 

d) generating, by the receiving member, a random number 
c between 0 and e-1; 

e) sending c to the sending member; 

f) computing, by the sending member a value y, where 
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y=rS° modn; 

g) sending y to the receiving member, 

h) determining by the receiving member that 

y*=xh*mod n; and 

i) if the equation is satisfied accepting that the sender has 
a valid certificate, wherein: 

n is the certifier's modulus; 
e is the public exponent of the certifier, 
h is the hash of the certificate body; and 
S is the signature on the certificate 
such that h=S* mod n. 

4. The method in claim 3 including the step of repeating 
the proof of knowledge protocol. 

5. The method of claim 1 including the step of encrypting 
the string with a current session key. 

6. The method of claim 1 wherein said proof of knowl- 
edge protocol includes the steps of: 

generating by the sending member; 

i) a number r and using r to compute a value x. where 
x=r* mod n, and 

ii) a number c and using r and c to compute a value y. 
where y=iS c mod n; 

sending to the receiving member x and y or y and cr, and 
detennining by the receiving member, who generates c in 
the same manner as the sending member, using y^xh c 
mod n to verify the value of x or solve for x, 
respectively, mat the value of c has been properly 
generated by the sending member wherein: 
n is the certifier's modulus; 
e is the public exponent of the certifier; 
h is the hash of the certificate body; 
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S is the signature on the certificate; a routine with a proof of knowledge protocol for estab- 

such that h=S* mod n. lishing the proof of the sending program's certificate. 

7. The method of claim 6 wherein the value of c is w ** 1S * A key escrow program as in claim 14 wherein 
dependent on x through a hash function. said routine with a proof of knowledge protocol includes 

8. The method of claim 7 wherein the value of c is made 5 interactive components for interacting with components in a 
dependent on a non-repeating value. proof of knowledge routine in the sending program. 

9. The method of claim 7 wherein the value of c is made N>. A public key escrow program as in claim 15 wherein 
dependent on a timestamp. said routine interactive components include: 

10. The method of claim 7 wherein the value of c is made a subroutine for computing a random number c and for 
dependent on the current session key. 10 sending c to the sending program; and 

11. A public key escrow program embedded in a software a subroutine for computing that 
product medium for communicating to a receiving program 

comprising: 

an encrypting session key; y=*h* mod c 

a law enforcement access field comprising the session key , , _^ . , ,. 

. . . . .,f\ * _ f ; where x and y are parameters provided by the sending 

encrypted by an escrow key with both encrypted by a . * r * iL 

/ J ;r ; program, e is the public exponent of the certifier of the 

annJV c ^' certificate, n is the certifier's modulus and h is the hash of 

a verification string including the escrow key; and ^ e certificate body. 

a sending member's components of a proof of knowledge 20 17, a public key escrow program as in claim 14 wherein 

protocol for establishing the proof of the sending sa id proof of knowledge protocol comprises a routine for 

member's certificate. computing that 

12. A public key escrow program as in claim 11 wherein 

the components of the proof of knowledge protocol include; y*=^h fl mod n 

a routine for computing a value x where 23 

x=r* mod n, and r is a random number, e is the public where x and y are parameters received from the sending 

exponent of the certifier and n is the certifier's program, c is a parameter generated in the same manner as 

modulus* m toe sending program, e is the public exponent and n is the 

. * . , modulus of the certifier of the certificate possessed by the 

and a routine for computing a value y where ^ . , . . , \. . . i 

oc j . J* . . ' . 30 sending program, and h is the hash on the body of the 

y=r S mod n, and S is the signature on the certificate _.. fi 6 y J 

and c is a random number provided by a receiving ^ °f ' . , 

member public key escrow program as in claim 17 wherein 

13. A public key escrow program as in claim 11 wherein c is made dependent on x and a non-repeating value 

the components of the proof of knowledge protocol include: A public key escrow program as in claim 14 wherein 

a routine for generating a numberr and a number c and a 35 said P«* * pledge P/* 0 ™ 1 conl P rises a routine for 

<. B . . . , t comoutine the value of x from 

routine for computing a value x and a value y where ^ & 

x=r* mod n. y=rS c mod n and c is made dependent on x y*^* n 

and a non-repeating value, and 

e is the public exponent of the certifier, n is the certifier's 40 where y and c are parameters received from the sending 

modulus and S is the signature on the certificate, program, e is the public exponent and n is the modulus of the 

14. A public key escrow program embedded in a software certifier of the certificate possessed by the sending program, 
product medium for responding to communications from a and h is the hash on the body of the certificate, and a routine 
sending program having a certificate comprising: for determining that the value of c generated from x in the 

a routine for receiving a law enforcement access field and 45 sarne manner as in the sending program is the same as the 

a verification string, for reconstructing a law enforce- value of c received from the sending program, 

ment access field from the received verification string, 20. A public key escrow program as in claim 19 wherein 

and for comparing the received law enforcement access c is made dependent on x and a non-repeating value, 
field with the reconstructed law enforcement access 

field; and ***** 
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